2 votes
Request support for WebBrowser sessions through web client / Devolutions Gateway.
Hi,
Thank you for your feature request. I know it may be ironic, but we don't have a feasible way to implement website entries going through Devolutions Gateway in a web client. In Remote Desktop Manager, we can spawn an embedded web view with a SOCKS proxy tunneled through Devolutions Gateway, but for a regular system browser, there is not really a method we can use to make specific websites or even specific tabs use different proxy settings. There is also the issue that we need to launch a local process to act as the SOCKS proxy, which we can't do from the web.
This being said, we're keeping the feature request in mind, and hopefully one day we will figure out a clever way to make it happen.
Best regards,
Marc-André Moreau
Hi,
Thank you for your feature request. I know it may be ironic, but we don't have a feasible way to implement website entries going through Devolutions Gateway in a web client. In Remote Desktop Manager, we can spawn an embedded web view with a SOCKS proxy tunneled through Devolutions Gateway, but for a regular system browser, there is not really a method we can use to make specific websites or even specific tabs use different proxy settings. There is also the issue that we need to launch a local process to act as the SOCKS proxy, which we can't do from the web.
This being said, we're keeping the feature request in mind, and hopefully one day we will figure out a clever way to make it happen.
Best regards,
Hello.
There are browser extensions like SwitchyOmega which allow this kind of behaviour, based on rules.
The destination can be specified per rule.
So I think it should be possible to do an implementation like this.
Best regards.
Marcel
ba413125-3c18-41c1-9c81-3f95850b3d33.png
Hi Marcel,
We looked into building a browser extension like SwitchyOmega in the past, but we never went all the way to something shippable. From what I recall, one issue is that a single browser extension can control proxy settings at once: our original plan was to add this as an optional feature in the Devolutions Workspace browser extension, but this would unfortunately mean building a separate browser extension to install only if you want it to control your proxy settings.
This being said, what we had internally required to have the browser extension to talk with RDM running locally, and have it launch the localhost SOCKS proxy to be injected into the browser dynamically with a PAC script. The way we make website entries work through Devolutions Gateway is by launching a program called jetsocat that connects to Devolutions Gateway with a WebSocket tunneling protocol while exposing a SOCKS5 proxy server on localhost. This is because we don't have a good way to make a SOCKS5 connection directly with Devolutions Gateway in a secure or practical manner (the JWT is too large to inject in the username or password field, and even if we did, SOCKS5 would reuse that token multiple times after sending it in plain text). This is also the issue that we don't really know when to close the SOCKS5 proxy if you just close the browser tab that needs it.
Supporting websites going through Devolutions Gateway in a regular system browser is still something we're interested in doing, if we can find a proper implementation path. For now, even with a lot of effort, I don't see a way this can be done without having to install one or more components on the client machine (browser extension, RDM, etc).
There is maybe another approach I'm researching right now, and you can tell me if it would be suitable for you: we've long had this idea of adding a lightweight VPN mode to Devolutions Gateway. Everything we've done so far requires having the application modify its connection sequence to explicitly go through Devolutions Gateway. With a VPN approach, we'd be creating a virtual network interface and routing specific IPs or subnets to go through it. This would require elevated permissions, but we've got Devolutions Agent coming up that may be leveraged for this.
It could look like this: in RDM, the Devolutions Gateway tunnel entry would have a "virtual network" mode. Instead of launching a SOCKS proxy, it would create a virtual network interface and modify routing rules to get specific IPs and subnets to go through it (your Intranet site). The creation of this virtual network interface and routing rules would require the installation of Devolutions Agent with an elevated system service we could call. Devolutions Agent would be configured once to trust tokens signed by Devolutions Server in the same way Devolutions Gateway does it today. Any application on the system could then access the Intranet site without using explicit proxy settings, until the Devolutions Gateway tunnel entry is closed, and the virtual network interface + routing rules deleted.
Let me know your thoughts on the various potential approaches, I wish there was a solution that didn't involve so much moving parts and development work.
Best regards,
Marc-André Moreau
Hello Marc-André.
The lightweight VPN approach could work, especially that you already have the concept of VPN for sessions.
I'm a bit afraid that opening the VPN + connecting to the remote interface would prove a bit longer than we would want to have for a web UI, but then again, it will probably still be faster than connecting to a jump host to open the webui.
With SwitchyOmega we need something to act as a proxy, so we use an SSH SOCKS tunnel for that.
We close the tunnel manually.
In general, for session ending, there could be a timeout defined by a setting on the web session.
You could then close the connection if there has been no traffic over the proxy for the defined duration.
But I agree, it's not an easy problem to tackle.
I'm afraid that's not very helpful as an answer.
Have a great week-end.
Marcel
Hi Marcel,
While a fully integrated solution has its challenges, there is something not too far away from your current solution that might work. If you already use an SSH SOCKS tunnel with SwitchyOmega, why not use a Devolutions Gateway tunnel entry in RDM to be exposed as a localhost SOCKS proxy on a known port instead? You'd just need to launch the Devolutions Gateway tunnel entry from RDM, then use SwitchyOmega to point to it. It's a bit manual, but it should definitely work: https://docs.devolutions.net/dgw/kb/knowledge-base/gateway-tunnel/
Best regards,
Marc-André Moreau